Implementatie van Webbeveiligingsheaders: JavaScript Content Security Policy (CSP)

In het huidige digitale landschap is webbeveiliging van het grootste belang. Cross-Site Scripting (XSS)-aanvallen blijven een aanzienlijke bedreiging voor websites en hun gebruikers. Content Security Policy (CSP) is een krachtige webbeveiligingsheader die XSS-risico's kan beperken door te controleren welke bronnen een browser mag laden voor een bepaalde webpagina. Deze uitgebreide gids richt zich op het implementeren van CSP met JavaScript voor dynamische controle en flexibiliteit.

Wat is Content Security Policy (CSP)?

CSP is een HTTP-response-header die de browser vertelt welke bronnen van inhoud zijn goedgekeurd om te laden. Het fungeert als een whitelist, die de herkomst definieert van waaruit bronnen zoals scripts, stylesheets, afbeeldingen, lettertypen en meer kunnen worden geladen. Door deze bronnen expliciet te definiëren, kan CSP voorkomen dat de browser ongeautoriseerde of kwaadaardige inhoud laadt die door aanvallers via XSS-kwetsbaarheden wordt geïnjecteerd.

Waarom is CSP belangrijk?

• Beperkt XSS-aanvallen: CSP is voornamelijk ontworpen om XSS-aanvallen te voorkomen door de bronnen te beperken waaruit de browser scripts kan laden.
• Verkleint het aanvalsoppervlak: Door de toegestane bronnen te controleren, verkleint CSP het aanvalsoppervlak dat beschikbaar is voor kwaadwillende actoren.
• Biedt een extra beveiligingslaag: CSP vult andere beveiligingsmaatregelen aan, zoals invoervalidatie en uitvoercodering, en biedt zo een diepgaande verdedigingsaanpak.
• Verhoogt het gebruikersvertrouwen: Het implementeren van CSP toont een toewijding aan beveiliging, wat het vertrouwen van gebruikers in uw website kan verbeteren.
• Voldoet aan compliance-eisen: Veel beveiligingsnormen en -regelgevingen vereisen of bevelen het gebruik van CSP aan om webapplicaties te beschermen.

CSP-richtlijnen: Het beheren van het laden van bronnen

CSP-richtlijnen zijn de regels die de toegestane bronnen voor verschillende soorten bronnen definiëren. Elke richtlijn specificeert een set bronnen of trefwoorden die de browser kan gebruiken om de corresponderende bron te laden. Hier zijn enkele van de meest gebruikte CSP-richtlijnen:

• `default-src`: Specificeert de standaardbron voor alle brontypen als een specifieke richtlijn niet is gedefinieerd.
• `script-src`: Specificeert de toegestane bronnen voor JavaScript-bestanden.
• `style-src`: Specificeert de toegestane bronnen voor CSS-stylesheets.
• `img-src`: Specificeert de toegestane bronnen voor afbeeldingen.
• `font-src`: Specificeert de toegestane bronnen voor lettertypen.
• `connect-src`: Specificeert de toegestane bronnen voor het maken van netwerkverzoeken (bijv. AJAX, WebSockets).
• `media-src`: Specificeert de toegestane bronnen voor mediabestanden (bijv. audio, video).
• `object-src`: Specificeert de toegestane bronnen voor plug-ins (bijv. Flash). Het is over het algemeen het beste om dit op 'none' in te stellen, tenzij absoluut noodzakelijk.
• `frame-src`: Specificeert de toegestane bronnen voor frames en iframes.
• `base-uri`: Specificeert de toegestane basis-URI's voor het document.
• `form-action`: Specificeert de toegestane URL's voor het verzenden van formulieren.
• `worker-src`: Specificeert de toegestane bronnen voor web workers en shared workers.
• `manifest-src`: Specificeert de toegestane bronnen voor applicatiemanifestbestanden.
• `upgrade-insecure-requests`: Instrueert de browser om onveilige (HTTP) verzoeken automatisch te upgraden naar veilige (HTTPS) verzoeken.
• `block-all-mixed-content`: Voorkomt dat de browser bronnen via HTTP laadt wanneer de pagina via HTTPS wordt geladen.
• `report-uri`: Specificeert een URL waar de browser CSP-schendingsrapporten naartoe moet sturen. (Verouderd, vervangen door `report-to`)
• `report-to`: Specificeert een groepsnaam gedefinieerd in de `Report-To`-header waar CSP-schendingsrapporten naartoe moeten worden gestuurd. Dit is het voorkeursmechanisme voor het rapporteren van CSP-schendingen.

Bron-expressies

Binnen elke richtlijn kunt u bron-expressies definiëren om de toegestane herkomst te specificeren. Bron-expressies kunnen omvatten:

• `*`: Staat inhoud van elke bron toe (niet aanbevolen voor productie).
• `'self'`: Staat inhoud van dezelfde herkomst (schema, host en poort) als het document toe.
• `'none'`: Staat geen inhoud van enige bron toe.
• `'unsafe-inline'`: Staat inline JavaScript en CSS toe (sterk afgeraden om veiligheidsredenen).
• `'unsafe-eval'`: Staat het gebruik van `eval()` en gerelateerde functies toe (sterk afgeraden om veiligheidsredenen).
• `'strict-dynamic'`: Staat dynamisch gecreëerde scripts toe om te laden als ze afkomstig zijn van een bron die al door het beleid wordt vertrouwd. Dit vereist een nonce of hash.
• `'unsafe-hashes'`: Staat specifieke inline event handlers met overeenkomende hashes toe. Vereist het verstrekken van de exacte hash.
• `data:`: Staat het laden van bronnen van data-URI's toe (bijv. ingesloten afbeeldingen). Wees voorzichtig met het gebruik.
• `mediastream:`: Staat toe dat `mediastream:` URI's worden gebruikt als mediabron.
• URL's: Specifieke URL's (bijv. `https://example.com`, `https://cdn.example.com/script.js`).

CSP implementeren met JavaScript: een dynamische aanpak

Hoewel CSP doorgaans wordt geïmplementeerd door de `Content-Security-Policy` HTTP-header aan de serverzijde in te stellen, kunt u CSP ook dynamisch beheren en configureren met JavaScript. Deze aanpak biedt meer flexibiliteit en controle, vooral in complexe webapplicaties waar de vereisten voor het laden van bronnen kunnen variëren op basis van gebruikersrollen, applicatiestatus of andere dynamische factoren.

De CSP-header instellen via een metatag (niet aanbevolen voor productie)

Voor eenvoudige gevallen of testdoeleinden kunt u CSP instellen met een ``-tag in het HTML-document. Deze methode wordt echter over het algemeen niet aanbevolen voor productieomgevingen omdat deze minder veilig en minder flexibel is dan het instellen van de HTTP-header. Het ondersteunt ook slechts een beperkte subset van CSP-richtlijnen. Specifiek worden `report-uri`, `report-to`, `sandbox` niet ondersteund in metatags. Het is hier opgenomen voor de volledigheid, maar wees voorzichtig!

            
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;">

            

              
                Copy
              
            
          

Nonces genereren met JavaScript

Een nonce (number used once) is een cryptografisch veilige willekeurige waarde die kan worden gebruikt om specifieke inline scripts of stijlen op een whitelist te plaatsen. De browser zal het script alleen uitvoeren of de stijl toepassen als het de juiste nonce-attribuut heeft dat overeenkomt met de nonce die is gespecificeerd in de CSP-header. Het genereren van nonces met JavaScript stelt u in staat om dynamisch unieke nonces voor elke aanvraag te creëren, wat de veiligheid verhoogt.

            
function generateNonce() {
 const randomBytes = new Uint32Array(8);
 window.crypto.getRandomValues(randomBytes);
 let nonce = '';
 for (let i = 0; i < randomBytes.length; i++) {
 nonce += randomBytes[i].toString(16);
 }
 return nonce;
}

const nonceValue = generateNonce();

// Add the nonce to the script tag
const script = document.createElement('script');
script.src = 'your-script.js';
script.setAttribute('nonce', nonceValue);
document.head.appendChild(script);

// Set the CSP header on the server-side (example for Node.js with Express)
app.use((req, res, next) => {
 res.setHeader(
 'Content-Security-Policy',
 `default-src 'self'; script-src 'self' https://example.com 'nonce-${nonceValue}'; style-src 'self' https://example.com; img-src 'self' data:;`
 );
 next();
});

            

              
                Copy
              
            
          

Belangrijk: De nonce moet aan de serverzijde worden gegenereerd en aan de client worden doorgegeven. De hierboven getoonde JavaScript-code is alleen voor demonstratiedoeleinden om de nonce aan de clientzijde te genereren. Het is cruciaal om de nonce aan de serverzijde te genereren om de integriteit te waarborgen en manipulatie door aanvallers te voorkomen. Het voorbeeld laat zien hoe de nonce-waarde vervolgens kan worden gebruikt in een Node.js/Express-applicatie.

Hashes genereren voor inline scripts

Een andere aanpak om inline scripts op een whitelist te plaatsen, is het gebruik van hashes. Een hash is een cryptografische vingerafdruk van de scriptinhoud. De browser zal het script alleen uitvoeren als de hash overeenkomt met de hash die is gespecificeerd in de CSP-header. Hashes zijn minder flexibel dan nonces omdat ze vereisen dat de exacte inhoud van het script van tevoren bekend is. Ze kunnen echter nuttig zijn voor het whitelisten van statische inline scripts.

            
// Example: Calculating SHA256 hash of an inline script
async function generateHash(scriptContent) {
 const encoder = new TextEncoder();
 const data = encoder.encode(scriptContent);
 const hashBuffer = await crypto.subtle.digest('SHA-256', data);
 const hashArray = Array.from(new Uint8Array(hashBuffer));
 const hashHex = hashArray
 .map((b) => b.toString(16).padStart(2, '0'))
 .join('');
 return `'sha256-${btoa(String.fromCharCode(...new Uint8Array(await crypto.subtle.digest('SHA-256', new TextEncoder().encode(scriptContent)))))}'`;
}

// Example usage:
const inlineScript = `console.log('Hello, CSP!');`;

generateHash(inlineScript).then(hash => {
 console.log('SHA256 Hash:', hash);
 // Set the CSP header on the server-side
 // Content-Security-Policy: default-src 'self'; script-src 'self' ${hash};
});

            

              
                Copy
              
            
          

Belangrijk: Zorg ervoor dat de hashberekening correct wordt uitgevoerd en dat de hash in de CSP-header exact overeenkomt met de hash van het inline script. Zelfs een verschil van één teken zorgt ervoor dat het script wordt geblokkeerd.

Dynamisch scripts toevoegen met CSP

Wanneer u scripts dynamisch toevoegt aan het DOM met JavaScript, moet u ervoor zorgen dat de scripts worden geladen op een manier die voldoet aan de CSP. Dit omvat doorgaans het gebruik van nonces of hashes, of het laden van scripts van vertrouwde bronnen.

            
// Example: Dynamically adding a script with a nonce
function addScriptWithNonce(url, nonce) {
 const script = document.createElement('script');
 script.src = url;
 script.setAttribute('nonce', nonce);
 document.head.appendChild(script);
}

const nonceValue = generateNonce();

// Set the CSP header on the server-side
// Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com 'nonce-${nonceValue}';

addScriptWithNonce('https://example.com/dynamic-script.js', nonceValue);

            

              
                Copy
              
            
          

Rapportage van CSP-schendingen

Het is cruciaal om CSP-schendingen te monitoren om potentiële XSS-aanvallen of misconfiguraties in uw CSP-beleid te identificeren. U kunt CSP configureren om schendingen te rapporteren aan een gespecificeerde URL met behulp van de `report-uri`- of `report-to`-richtlijn.

            
// Set the CSP header on the server-side
// Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;
// Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report"}]}

// Example Node.js endpoint to receive CSP reports
app.post('/csp-report', (req, res) => {
 console.log('CSP Violation Report:', req.body);
 res.sendStatus(204); // Respond with a 204 No Content status
});

            

              
                Copy
              
            
          

De browser stuurt een JSON-payload met details over de schending, zoals de geblokkeerde bron, de overtredende richtlijn en de document-URI. U kunt deze rapporten vervolgens analyseren om beveiligingsproblemen te identificeren en aan te pakken.

Let op: de `report-uri`-richtlijn is verouderd en `report-to` is de moderne vervanging. U moet zowel de `Report-To`-header als de CSP-header configureren. De `Report-To`-header vertelt de browser waar de rapporten naartoe moeten worden gestuurd.

CSP in 'Report-Only'-modus

CSP kan in 'report-only'-modus worden geïmplementeerd om uw beleid te testen en te verfijnen zonder bronnen te blokkeren. In de 'report-only'-modus zal de browser schendingen rapporteren aan de gespecificeerde URL, maar het beleid niet handhaven. Dit stelt u in staat om potentiële problemen te identificeren en uw beleid aan te passen voordat u het in productie handhaaft.

            
// Set the Content-Security-Policy-Report-Only header on the server-side
// Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;
// Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report"}]}

// Example Node.js endpoint to receive CSP reports (same as above)
app.post('/csp-report', (req, res) => {
 console.log('CSP Violation Report:', req.body);
 res.sendStatus(204); // Respond with a 204 No Content status
});

            

              
                Copy
              
            
          

Best practices voor het implementeren van CSP

• Begin met een strikt beleid: Begin met een strikt beleid dat alleen de noodzakelijke bronnen toestaat en versoepel het geleidelijk indien nodig op basis van schendingsrapporten.
• Gebruik nonces of hashes voor inline scripts en stijlen: Vermijd waar mogelijk het gebruik van `'unsafe-inline'` en gebruik nonces of hashes om specifieke inline scripts en stijlen op de whitelist te plaatsen.
• Vermijd `'unsafe-eval'`: Het uitschakelen van `eval()` en gerelateerde functies kan het risico op XSS-aanvallen aanzienlijk verminderen.
• Gebruik HTTPS: Dien uw website altijd via HTTPS aan om te beschermen tegen man-in-the-middle-aanvallen en de integriteit van uw bronnen te waarborgen.
• Gebruik `upgrade-insecure-requests`: Deze richtlijn instrueert de browser om onveilige (HTTP) verzoeken automatisch te upgraden naar veilige (HTTPS) verzoeken.
• Gebruik `block-all-mixed-content`: Deze richtlijn voorkomt dat de browser bronnen via HTTP laadt wanneer de pagina via HTTPS wordt geladen.
• Monitor CSP-schendingen: Monitor regelmatig CSP-schendingsrapporten om potentiële beveiligingsproblemen te identificeren en uw beleid te verfijnen.
• Test uw beleid: Test uw CSP-beleid grondig in 'report-only'-modus voordat u het in productie handhaaft.
• Houd uw beleid up-to-date: Herzie en update uw CSP-beleid regelmatig om veranderingen in uw applicatie en het beveiligingslandschap te weerspiegelen.
• Overweeg het gebruik van een CSP-generatortool: Verschillende online tools kunnen u helpen een CSP-beleid te genereren op basis van uw specifieke vereisten.
• Documenteer uw beleid: Documenteer uw CSP-beleid en de redenering achter elke richtlijn duidelijk.

Veelvoorkomende uitdagingen en oplossingen bij CSP-implementatie

• Legacy code: Het integreren van CSP in applicaties met legacy code die afhankelijk is van inline scripts of `eval()` kan een uitdaging zijn. Refactor de code geleidelijk om deze afhankelijkheden te verwijderen of gebruik nonces/hashes als tijdelijke oplossing.
• Bibliotheken van derden: Sommige bibliotheken van derden kunnen specifieke CSP-configuraties vereisen. Raadpleeg de documentatie van deze bibliotheken en pas uw beleid dienovereenkomstig aan. Overweeg het gebruik van SRI (Subresource Integrity) om de integriteit van bronnen van derden te verifiëren.
• Content Delivery Networks (CDN's): Wanneer u CDN's gebruikt, zorg er dan voor dat de CDN-URL's zijn opgenomen in de `script-src`, `style-src` en andere relevante richtlijnen.
• Dynamische inhoud: Dynamisch gegenereerde inhoud kan moeilijk te beheren zijn met CSP. Gebruik nonces of hashes om dynamisch toegevoegde scripts en stijlen op de whitelist te plaatsen.
• Browsercompatibiliteit: CSP wordt ondersteund door de meeste moderne browsers, maar sommige oudere browsers hebben mogelijk beperkte ondersteuning. Overweeg het gebruik van een polyfill of een server-side oplossing om CSP-ondersteuning voor oudere browsers te bieden.
• Ontwikkelingsworkflow: Het integreren van CSP in de ontwikkelingsworkflow kan wijzigingen in bouwprocessen en implementatieprocedures vereisen. Automatiseer de generatie en implementatie van CSP-headers om consistentie te waarborgen en het risico op fouten te verminderen.

Wereldwijde perspectieven op CSP-implementatie

Het belang van webbeveiliging wordt universeel erkend, en CSP is een waardevol instrument om XSS-risico's in verschillende regio's en culturen te beperken. De specifieke uitdagingen en overwegingen voor het implementeren van CSP kunnen echter variëren afhankelijk van de context.

• Regelgeving inzake gegevensprivacy: In regio's met strikte regelgeving inzake gegevensprivacy, zoals de Europese Unie (GDPR), kan het implementeren van CSP helpen om een toewijding aan de bescherming van gebruikersgegevens en het voorkomen van datalekken aan te tonen.
• Mobile-First Ontwikkeling: Met de toenemende prevalentie van mobiele apparaten is het essentieel om CSP te optimaliseren voor mobiele prestaties. Minimaliseer het aantal toegestane bronnen en gebruik efficiënte cachingstrategieën om netwerklatentie te verminderen.
• Lokalisatie: Bij het ontwikkelen van websites die meerdere talen ondersteunen, moet u ervoor zorgen dat het CSP-beleid compatibel is met de verschillende tekensets en coderingsschema's die in elke taal worden gebruikt.
• Toegankelijkheid: Zorg ervoor dat uw CSP-beleid niet per ongeluk bronnen blokkeert die essentieel zijn voor toegankelijkheid, zoals screenreader-scripts of stylesheets voor ondersteunende technologie.
• Wereldwijde CDN's: Wanneer u CDN's gebruikt om inhoud wereldwijd te leveren, kies dan CDN's met een sterke beveiligingsreputatie en functies zoals HTTPS-ondersteuning en DDoS-bescherming.

Conclusie

Content Security Policy (CSP) is een krachtige webbeveiligingsheader die het risico op XSS-aanvallen aanzienlijk kan verminderen. Door CSP met JavaScript te implementeren, kunt u uw beveiligingsbeleid dynamisch beheren en configureren om te voldoen aan de specifieke eisen van uw webapplicatie. Door de best practices in deze gids te volgen en CSP-schendingen continu te monitoren, kunt u de beveiliging en het vertrouwen van uw website verbeteren en uw gebruikers beschermen tegen kwaadaardige aanvallen. Het omarmen van een proactieve beveiligingshouding met CSP is essentieel in het steeds veranderende dreigingslandschap van vandaag.